This application pertains to custom scheduling and controlling of a multifunction printer (MFP), and more particularly, to methods and systems for providing custom scheduling and control of the MFP throughout its lifetime.
In an effort to reduce the complexities, costs, and excessive space associated with function-specific printing and scanning machines, MFPs are rapidly being adopted by businesses and individuals the world over. MFPs attract a wide array of users from small start-up companies to large established businesses. The attraction may be attributed to the MFP's versatility as a single machine with multiple capabilities—such as printing, scanning, copying, faxing, and networking.
Conventionally, developers of MFPs (e.g., engineers, technicians, or other developers) have ready access to firmware operating within an MFP during a development cycle. The development cycle may begin in an engineering lab and end at an MFP factory, whereupon the MFP is shipped to a customer or other user. During the development cycle, the developers can monitor performance of the MFP in a relatively effortless manner using specialized tools within a specific development environment. Also, the developers may establish favorable parameters within which the MFP operates according to the performance measurements obtained within their specific development environment. However, once the MFP has been shipped from the factory to the user, it becomes difficult—if not impossible—for the developers to make alterations to the operating parameters of the MFP. Therefore, the developers do not have visibility or control of the MFP throughout the lifetime of the MFP.
Operating environments of MFPs are unique because users have diverse sets of requirements, which may considerably fluctuate from user to user. Some users may require an operating environment that prioritizes one MFP operation, such as printing, over another operation such as scanning. Similarly, usage patterns of the MFP may considerably fluctuate from user to user. Some usage patterns may require the prioritization of one MFP operation, such as printing, over another operation such as scanning. The prioritization of MFP operations requires the prioritization of processor resources of an MFP. The dedication of processor resources to a given MFP operation may come at the expense of other MFP operations.
For example, if the printing operation is currently occupying a significant portion of the processor's resources, other operations such as scanning or copying may be impeded. Or, if the scanning or copying operations are currently occupying a significant portion of the processor's resources, the printing operation may be impeded. As a result, some operations that may be considered more urgent than others during a given period of time could be undesirably delayed. If the user considers the scanning operation to have a higher urgency than ongoing printing operations, the MFP may nonetheless have been constructed to dedicate processor resources first to the printing operation and second to the scanning operation. Similarly, if the usage patterns indicate that the scanning operation should have a higher urgency than ongoing printing operations, the MFP may nonetheless have been constructed to dedicate processor resources first to the printing operation and second to the scanning operation. This may affect work flows to the point of causing loss of time, decreased efficiency, and wasteful usage, which ultimately leads to—at the very least—frustration, or worse, lost profits.
Moreover, the user may consider certain times of day to be more demanding for one operation and less demanding for another operation. Similarly, the usage patterns of the MFP may dictate that certain times of day are more demanding for one operation and less demanding for another operation. For example, if the MFP is used more often in the morning to fulfill urgent printing requests, in the afternoon to fulfill urgent copying requests, and in the evening to fulfill urgent scanning requests, a conventional MFP may not allocate resources appropriately. To make matters worse, once the MFP has been shipped from the factory to the user, the developers or users cannot easily make alterations to the internal task scheduling policies of the MFP based on either the user requirements or the usage patterns of the MFP.
As a result, a developer must therefore attempt to replicate the user's particular requirements or usage patterns in a lab or at the user's location, and then attempt to make alterations to the internal task scheduling policies of the MFP to accommodate the simulated user requirements or usage patterns. The replication may never be precise enough for the developer to formulate the most favorable alterations to the internal task scheduling policies based on the specific user requirements or usage patterns. Even where alterations to the internal task scheduling policies are formulated to some lesser degree of accuracy through the replication effort, after spending time and money on such an effort, the manufacturer of the MFP may have to design a special software patch in an attempt to remedy the inefficiencies. This can be inconvenient to the user—and costly to the manufacturer—because of the interruption that results from taking the MFP offline to install the special patch, and the effort expended by the manufacturer to design and manage the special patch.
Furthermore, the conventional approach for addressing customer problems fails to provide an efficient method of updating the internal scheduling policies of the MFP based on either the user requirements or usage patterns of the MFP. In other words, the turn-around time for diagnosing a problem and providing a solution to the user is prohibitively long.